【レポート】 SID201 – エンタープライズでのIAM: バンガードはいかにして、アジリリティ、ガバナンスとセキュリティのバランスを両立させたか #reinvent #sec201

はじめに

re:Invent 2017の「SID201 - エンタープライズでのIAM:バンガードはいかにして、アジリリティ、ガバナンスとセキュリティのバランスを両立させたか」を聴講したのでレポートします。
講演者は、AWSのReef Dsouzaさんと バンガードのRajeev Sharmaさんです。
前半はReefさん、後半はRajeevさんの発表でした。

原題は、「SID201 - IAM for Enterprises: How Vanguard Strikes the Balance Between Agility, Governance, and Security」です。

セッション概要

バンガードにとって、AWSのアイデンティティとアクセス管理（IAM）オブジェクトの作成を管理することは、開発者の速度とコンプライアンスのバランスをとるためのキーです。
このセッションでは、バンガードがIAMの役割をどのように設計してAWSリソースの爆発的な範囲を制御し、開発者にとってシンプルさを維持するかを学びます。 また、ガバナンスを管理し、AWSリソース全体の可視性を向上させるベストプラクティスを共有します。

レポート

エンタープライズセキュリティの目的地

• 徹底した防御
• 職務の分離
• 最小権限の原則に従う

分離のためにAWSアカウントを利用する

セキュリティ境界
アカウント内のユーザーとデータを分離する。
そのアカウントのセキュリティポリシーに従い、影響範囲を小さくする。

リソースの封じ込め
アカウント内で作成されたリソースはその特定のアカウントに制限される。
AWSリソースは、アカウントごとにハード制限とソフト制限によって制約される。

財務コントロール
請求および財務詳細は、アカウントごとに定義および管理される。

IAMとコアコンポーネント

ユーザ、グループ、ロール、ポリシー。
ポリシーはJSONで書かれたアクセス情報。

AWSのIDフェデレーション

IDフェデレーションを使う前では、ユニークな認証情報、長期間有効なキーがある。
IDフェデレーションを使うと、シングルサインオンや一時的なトークンを利用できる。

スケールにおける試練

• 多くのAWSアカウント
• 多くのユーザー
• 多くのIAMロール
• 適切なリソース権限の粒度
• トレサビリティ
• Idpが利用できない?

バンガードについて

バンガードは世界最大の投資会社の1つで、低コストの投資信託、ETF、アドバイス、および関連サービスを幅広く提供する。
すべての投資家のための立場を取って公平に扱い、投資成功のための最良のチャンスを与えることを目的にしている。

信頼のできる情報源

• CIS AWS Foundations
  • 実際の脅威に対してシステムを強化するベンチマーク
• NIST 800-53
  • 米国の政府機関のセキュリティ管理に利用される
• SOC 2
  • セキュリティ、可用性、および処理の整合性に関連するサービス組織のコントロールについて記載されている
• GS007
  • オーストラリアの政府監査と保証のスタンダードボード
• バンガードの内部セキュリティポリシー

コンプライアンス要件

• ワークフロー
  • アクセスが自動的に提供されること
• クレデンシャル管理
  • パスワードおよびログインパラメーターが、企業ポリシーと手順に従って設定されること
• ガバナンス
  • ユーザーアクセスが調整されていること
  • ユーザーアクセスが管理者によって、半年ごとにレビューされていること

IAMユーザーを各々のAWSアカウントに作成した場合

長期間有効なキー、MFAトークン、パスワードが多数作成され管理が難しい。

最初の役割管理

ユーザーがロールをリクエストすると、ロールオーナーは承認するか判断する。
承認された場合、LDAPを更新する。
リクエストはアーカイブされ、監査に利用される。
SAMLやSTSのようなフェデレーションを利用する。

なぜIAMロールにフェデレートするのか

• アクセスキーが漏えいするリスクが大幅に低減される
• 既存の企業ポリシーとツールを活用する
• 新しいメンバーや辞めるメンバーに対応する

ロールの合理化とは？

リスクとアクセスニーズに基づいた役割の再設計。
プロビジョニング戦略と以前の利用状況データから、実装する候補ロールのリストを作成する。

プロセスステップ

1. 現状のロールとポリシーをロールオーナーと見直す
2. CloudTrailデータの収集と解析または、アクセスアドバイザーの見直しを行う
3. 職位と比較する
4. 現在のロール/ポリシーを改良する
5. LDAPまたはIdpの割り当てを更新する

ビフォーアフター

大量のアクセス権を持ったエンジニアリングロールがほとんどのユーザーに与えられていた。
変更後は、新しい4つの細かいロールが作成された。
管理者（①IAM管理者、②脅威アナリスト）、クリエイター（③ソリューションエンジニア）、コンシュマー（④DBユーザー）

Audit time

以下のチェックを満たすことができた。

• アクセス権のある本当の人物を知っている
• ユーザー名の強制が可能
• 一貫したパスワードポリシーを設定可能
• 長期間有効なアクセスキーを排除した
• ロールはアカウントにスコープされている
• 明確に要求プロセスが定義されている
• ロールに正しいポリシーが割り当てられている
• ロールと職位がマッチしている

最後に

SID201のレポートをお届けしました。